Systems and methods for managing recruiting and player allocations within sporting competitions

ABSTRACT

System  10  implemented over network  120,  is a semi-autonomous bot  14  for managing recruiting and player allocation functions, for sporting grades and sporting leagues, with sub-functions for finding and confirming recruits, controlled through administrative interface  11.    
     The bot uses recruit interface  12,  a discrete page on league website  17,  to accept allocation requests from new players or the like, i.e. requests to join the league generally or to join particular teams. Using the preferences and personal details submitted in the recruit interface the bot can generate ranked lists  1411  of the most suitable teams for the initiator of the allocation. Ranking is performed by allocation algorithm  141  and uses team population data, team skill, team recruiting status (set through private team interface  13 ), team congruence with the initiators personal details (particularly age, gender etc), and previous allocation requests received by said team. 
     The bot either sequentially or in parallel sends allocation requests to said teams using either SMS&#39;s  181  sent through SMSC  18,  emails sent through network  120,  or logs sent to team interface  13,  as a means of finding a team interested in receiving the initiator, preferentially targeting teams whose reception of the player would balance the grade, i.e. preferencing underpopulated or under skilled teams. If a team is found, notifications are sent and team lists are updated, if not, the initiator is added to player pending list  162,  awaiting further action from an administrator. 
     The allocation process may be initiated through the recruit interface, or may be initiated by the bot  14,  by autonomously prompting selected parties to have teams found for them, particularly dropout players, or fill/temp players. By doing so the league bot can provide an easy process for dropout players to be reintegrated into the competition (and also confirm their interest/non-interest), or provide underemployed players the packaged option of playing more regularly.

The present invention is a sporting league ‘bot’ that semi-autonomouslymanages new player allocations within sporting competitions, in such away that grade character is enhanced, and performs recruit targeting onparticular groups.

Many people play in local sports leagues and the like in many differenttypes of sport, including for example basketball, netball, indoorsoccer, and indoor cricket.

Typically, a league or organising body will set up matches, withingrades grouped by a combination of skill, age, gender etc, and providegame officials and other support, and registered teams will play once aweek at a designated time in a local hall, sports centre or the like.

Individuals wanting to join a particular competition, particular indoorcompetitions, can either communicate their interest with teams directly,or register their interest generally with the league, usually with anofficial charged with dealing with new recruits. Said registrations arealmost exclusively processed when making rosters in the followingseason, rather than immediately. This process includes a range ofbarriers of entry for individuals looking to join competitions. There iseither a delay attached to registrations processed by the leagueofficial, which can be as long as an entire sporting season, or thedifficulty associated with contacting teams directly, or finding anadministrator willing to contact teams directly, on said individualsbehalf. Such processes obviously impact on the ease with which anindividual can join a sporting competition, and can be off putting tonew players.

A separate but related function performed by sporting leagueadministrators relates to ensuring grades take on a particular characterwith respect to team populations and the homogeneity of team skill.Grades are groups of teams of similar skill which compete against eachother within the competition. When grade character is suitablycontrolled by an administrator, i.e. team populations are robust andteam skill is relatively even, the grade becomes less likely to beassociated with game forfeits, and less likely to be associated withplayer and team dropouts, than relatively uncontrolled grades, i.e.grades made up of under populated teams, or teams of widely differentskill levels.

Team forfeits and dropouts have substantial costs. A single forfeit in abasketball league can cost up to $100, once team fees, referee fees andthe like are accounted for. Thus, methods for reducing forfeits anddropouts particularly when scaled up to entire leagues, can havesignificant financial repercussions.

An aim of the present invention is to provide a mechanism for allocatingindividuals, particularly new players, to sporting teams, whilepreferentially performing allocations in a way that complements gradecharacter. The mechanism should also ‘manage’ player participation, byprompting particular parties for allocations.

Viewed from one aspect, the present invention provides a recruit andallocation management system for a sporting league implemented over anelectronic communications network, including:

a league ‘bot’, a semi-autonomous program that manages the playerallocation process, including performing strategic individual/teamallocations, and actively identifying and prompting parties forallocations;

an administrative interface, for league administrators to set botpreferences;

discrete team interfaces, for teams to interact with the bot, includingsetting team recruiting status, and viewing logs of allocation requestsmade to said team;

a recruit interface, for recruits/individuals to interact with the bot,including initiating a particular or general allocation request;

a database containing league data, bot lists, administrator preferences,team preferences, recruit details etc;

The present invention may for example be implemented through a websiteon the internet, a direct interface through a suitable communicationssystem, including electronic messaging in general, or some combination,and provides a discrete mechanism for performing recruitment andallocation functions, particularly of a strategic nature. Saidallocations might be initiated independently by an individual (e.g. by anew player looking to join a competition) through a suitable interface(e.g. a ‘recruit’ web page or the like) or a request made through adirect communication to the system (e.g. an SMS, or the like, sent tothe system), or might be initiated dependently, based on an individualsresponse to an allocation request ‘prompt’ sent by the system. Anallocation request prompt is the active component of therecruitment/allocation system, such that a prompt might be sent to cueparticular groups to play in the current season and have team found forthem, for example ‘dropout’ players, whose team played the last but notthe current season, and ‘underemployed’ players, who might currentlyplay in a temporary fashion only, are likely candidates for prompts,which if responded to in the affirmative, might initiate an allocation.

The allocation process, of finding a suitable and willing team for theinitiator of an allocation request, be it a request made through arecruit interface or from a prompt, might be executed through automated,interactive messages (e.g. SMS, instant messages, email and the like),or through posts to web interfaces (e.g. private ‘team pages’, or apractical equivalent), sent sequentially or in parallel to prospectiveteams (i.e. teams identified as suitable and potentially in need ofplayers by the system), such that said teams are able to confirm aninterest in a particular recruit, through making an appropriate reply tothe allocation request, e.g. a reply message, to an SMS, or clickablehyperlink, to an email, or a field, to a message embedded into a teaminterface, thus allowing the initiator to be allocated speedily andwithout administrative effort to a team.

The bot is two dimensional, including a processing dimension forconstructing ranked lists of teams suitable for a particular initiator(i.e. for constructing ‘allocation rank lists’). Ranking is performedthrough processing a range of variables including age/gender congruence,team skill/performance, team population, team substitutes, teamrecruiting status, admin preferences and the number of previousallocation requests sent to said team. Using these variables,allocations can be preferentially directed to teams matching thespecification of the initiator, in the most need of players and who havenot rejected a number of previous allocation requests, and restrictedfrom being sent to unsuitable teams.

The management dimension of the bot accepts allocation initiations, fromnew players and the like, and communicates with teams to find a positionfor the initiator. As a process, an allocation might take the form of aparty initiating an allocation request e.g. using a recruit interface onleague website, to express a specific or general interest in joining thesporting competition. Within that request the initiator might inputpersonal details and preferences. Said data is submitted to the systemwhere it is processed by the rank algorithm to create an allocation ranklist, which is used as a contact list for communicating with teams, andasking said teams to receive said initiator. If a team is found, theparties are notified, and the league database is modified to reflect thechanges. If a team is not found, the player details are logged in aplayer pending list, for the follow-up attention of administrators.

The bot can also function to prompt selected individuals to be an‘initiator’, i.e. to authorize an allocation. The prompt might take theform of a communication, including an email, SMS, instant message, or asuitable equivalent, with an appropriate reply instruction, sent to aparty with a reasonable chance of replying positively to said prompt,including dropout players, that played in the last season but not thecurrent season, and/or fill/temp players, that play for teams in thecurrent season but only play occasionally, e.g. playing between 5% and40% of games.

Confirmations to said prompts, indicating that said dropout orunderemployed player would like a team found, or to play more regularly,might initiate the same process as an independent allocation requestmade through the recruit interface, such that said dropout orunderemployed player might be found a team using the ordinary allocationprocess. Using this method a percentage of dropout players, the biggestsource of ‘loss’ for sporting competitions, and a percentage ofunderemployed players, might be persuaded to play or play more in thecurrent season.

In this way the bot can automate the administrative tasks associatedwith recruiting and allocation, in such a way that grade character isenhanced, and systems can be put in place that actively follow-updropouts and underemployed players, to maximize the bot's capability ofaddressing losses associated with dropouts.

The present invention could apply to a range of sports including forexample basketball, netball, soccer (e.g. indoor soccer, including5-a-side or 6-a-side soccer), indoor cricket, darts or any other teamsport. The system would be particularly useful for sports with highbarriers to entry, or in which team population impacts directly on gameforfeits, team dropout rates and the like, or where the sport is heavilysegmented with respect to skill.

The present invention is relevant to both leagues (e.g. footballleagues, basketball associations etc) and bodies which co-ordinateleagues (e.g. VFL, Basketball Victoria, etc) irrespective of whetherthey are for profit or not-for-profit bodies, such that the bot‘recruit’ interface might be nested in the websites of either leagues orleague coordinating bodies, as a centralized means of requestingallocations to a local sporting team.

The administrative interface is a private space for administrators andmight take the form of a private webpage, a program/application or thelike, or any other suitable framework, and is used by leagueadministrators to set bot preferences, particularly the scope ofautomatic function, and the method by which automatic functions areexecuted, and also be used to view the statistical analysis which guidesthe allocation process as a general insight into grade health.

The administrative interface might include fields for managing theallocation process, including checkboxes or the like which might be usedto temporarily or permanently disable the allocation system, by hidingor blocking the ‘recruit’ interface (where allocations might beinitiated), or displaying an error message or the like when a player orindividual initiates an allocation. Sub-fields might include setting theparticular method by which allocations are performed, including whetheremails, SMS's, instant messages, messages posted to discrete teamweb-pages, or the like, or some combination, are used as a means ofgaining confirmations from teams, confirmations from the allocationinitiator, and the like, and sending notifications to parties once anallocation is made. Sub-fields might also include whether or not toexclusively target ‘recruiting teams’ within the allocation process,i.e. teams setting their status as ‘recruiting’ within a suitable ‘team’page, or the like. Selecting this setting might limit the allocationprocess to only send allocation requests to teams that identifythemselves as ‘recruiting’.

The administrative interface might also include fields for managingwhether or not prompts are sent to dropout players. This might take theform of a check-box, drop-down box, or a practical equivalent, forturning ‘on’ or ‘off’ prompts sent to dropout players, and might includesub-fields putting controls on said automatic prompts, e.g. fields forsetting an upper limit on the amount of times a dropout player might beprompted within a given time-frame (e.g. setting a maximum number of 2prompts per dropout player per year), and/or fields setting the methodby which prompts are sent (e.g. SMS, email or the like), and/or fieldsfor defining the time elapsed since ‘dropout’ that a player mightreceive prompts (e.g. not targeting dropouts more than 6 months old orthe like), and/or fields for defining seasons/grades/groups which mightbe uniquely targeted or not targeted for prompts (e.g. no groups underthe age of x, only dropouts from A grade, or an equivalent group basedrule). In this way, although the process might be regarded as automatic,the administrator can manage the character of the automatic prompting tofit the needs and values of the league, particularly with respect to theaggressiveness with which dropout players are targeted forre-registration through prompts.

The administrative interface might also include fields for managingprompts for underemployed players. These fields might take on a similarcharacter to that described for prompts for dropout players, includingunique fields to turn ‘on’ or ‘off’ the sending of prompts tounderemployed players, and/or sub-fields for specifying the point, orrange, at or within which a player is defined as underemployed (e.g.participating in less than 50% of games, or between 5% and 30% of gamesetc), and/or fields specifying the method by which prompts are sent(e.g. email, SMS, instant message etc), and/or fields for specifying thefrequency and/or upper limit of prompts (e.g. how often and/or themaximum number of prompts sent to a particular underemployed player),and/or fields for specifying the groups targeted or not targeted forprompts (e.g. target underemployed players older than x, from A and Bgrade only, or equivalent group based rules), or other sub-fields whichmight be relevant to the prompting of underemployed players as judged bya suitably qualified person.

Using said fields and sub-fields an administrator might specify whetherdropout and underemployed players are targeted by the bot for moreregular playing using prompts, if so which players are regarded asdropouts or underemployed, how prompts are sent, which groups areexcluded, and upper limits or the like on prompts.

The administrative interface might also display part of the statisticalanalysis underpinning the allocation process, providing theadministrator the opportunity to make manual allocations, and provide auseful insight into the health of particular grades. The analysis mightinclude lists of teams ranked by skill, e.g. using an algorithmprocessing win/loss data and team points for/against, to create aproximate measure of skill. The measure might be attached to apercentile to provide a context, e.g. that the team is performing in thetop 2% of teams generally, or the like. The same could be achieved forpopulation, and include data on active team-members per game and activesubstitutes per game.

Such analysis provides a good snapshot and unique insight into thewellbeing of a particular grade, and can identify teams which areplaying ‘above’ or ‘below’ a particular grade, grades which might needto be split, having two tiers of skill levels etc. The above describedanalysis, used by the bot within the allocation process, might augmenttraditional methods for identifying over or under performing teams orunder-populated teams, which presently relies on the experience, goodjudgement and attentiveness of the league administrator, and superficialstructures like ladders, which fail to include all the required data.

The administration interface more generally might take a variety offorms, including a private web page, downloadable or cached program, ora practical equivalent, which provides fields for controlling botsettings, particularly whether or not the bot can perform automatedallocations, and related sub-fields, and/or whether or not the bot mightapproach dropout players, and related sub-fields, and/or whether or notthe bot might approach underemployed players, and related sub-fields.Said interface might also include tools to navigate the bot statisticaloutputs. The interface might use any suitable coding platform, includingC Sharp, VB, flash, java, some combination, or some practicalequivalent, as judged by a reasonably qualified person.

The team interface is a private space for teams to set preferences withrespect to recruiting, and control related functions, including beingable to block allocation requests. The team interface might take theform of a private web page in a sporting league website, or any othersuitable format or platform, including a direct access platform (e.g.accessible through sending communications directly to the system).

The interface might include fields for updating a centralized team‘recruiting’ status tool, i.e. for a team to identify itself as‘recruiting’. Teams identified as recruiting might be preferenced and/or‘unlocked’, depending on related administrative settings. Thus, teamrecruiting status might effect the allocation process in-so-far asadministrators specify, such that the bot might only allocate players to‘recruiting’ teams, if specified by the administrator, or if notspecified, might simply preference said recruiting teams, byartificially increasing their ‘rank’, or the like, within the allocationprocess. Recruiting teams might also be marked as such on public leaguedata structures, including league ladders, rosters and the like, oradded to a centralized list of recruiting teams, to optionally advertiserecruiting status. Conversely the team might use an appropriate field toblock all allocation requests, particularly if for example, the team hasa low team population, the administrator is allowing allocation requeststo non-recruiting teams, but the team is not interested in additionalplayers. In said situation it would be useful for said team to blockallocation requests.

Sub-fields relating to recruiting status might include specifying thenumber of recruits needed, specifying the preferred and approximateskill of said recruit, specifying the required ‘position’ of saidrecruit (e.g. center, goal-keeper etc), or any other variable whichmight be relevant in describing a recruit, and/or specifying a commentor message attached to the teams recruiting status. Such a message wouldbe viewable within, for example, the recruit interface, and might beused generally to inform recruits of special requirements orconsiderations of said team.

The team interface might also include logs or the like of allocationrequests received by said team. For example if emails were selected asbeing used to make allocation requests, the log might include when suchan email was sent, the response made to said request, including whetherthe team accepted the allocation request, or rejected the request eitherby providing a negative response or allowing the request to timeout.Sub-fields within the log might allow the team to re-initiate anallocation, in a situation where the initiator was not ultimatelyallocated a team, that might act procedurally like an affirmativeresponse to a natural allocation request, such that the initiator mightbe sent a confirmation message that a team accepted the allocationrequest, and might call for final confirmation from said initiatorbefore the allocation is executed. For example, this would allow a teamrepresentative to reject an initial allocation request, get consensusfrom the team, and accept said request later, if the individual makingthe request was still available. Logs might also be used as the methodby which teams respond to allocation requests, i.e. acting in place ofemails or SMS's sent to a team representative.

The team interface need not take a specific form, e.g. a webpage,application, direct access system or the like, provided said interfaceis consistent with the before mentioned description, including, at theleast, the capacity for a team to update a centralized team recruitingstatus, such that ‘recruiting status’ is any team constructed electronicsignature which indicates a team is in want of players. The interfacemight also include logs or the like of allocation requests and fields tore-initiate allocations in particular circumstances. Any format whichfacilitates this capacity, including a private team webpage, acentralized league page with a recruiting status tool, a third partywebsite with a recruiting status tool, a direct service whereby a directmessage and/or contact is used to update a recruiting status, e.g.through an SMS, MMS, a voice message or a practical equivalent, mightalso be used. The interface might use any coding framework, anyelectronic device and or network to facilitate the aforementioneddescription, as judged by a suitably qualified person.

The recruit interface is the portal by which new players or individualsmight create or initiate allocation requests. Related functions mightallow said individuals or players to optionally view lists of‘recruiting’ teams, view preferences and messages attached to said teamrecruiting status, mark specific or general interest in joining aleague, and insert personal details or preferences to assist in teamallocation.

To assist in team allocation the interface might include fields forinputting personal details including name, age, gender, email address,mobile phone number and the like, or details about previous playingexperience, including whether the individual is a ‘new’ or ‘existing’player, previous playing duration, previous playing position if relevant(e.g. goal keeper), grades and the like. These preferences might used bythe bot in the allocation process, particularly restricting allocationsby gender and age, and might also be restrictively shown to teams in theconfirmation process (e.g. “Bot: an X year old player, of X yearsexperience, has asked to join your team, reply ‘yes’ if you would liketo accept said player”. Thus, personal preferences might be used bothwithin the allocation process (i.e. process by the algorithm), and inrelated functions (e.g. communicating with teams).

The interface might include fields for creating or initiatingallocations, e.g. a ‘find me a team’ type field, usable once personaldetails are entered, including sub-fields for defining the character ofa specific allocation request, including sub-fields for specifying theseason which teams might be drawn from (e.g. men's, women's, mixed etc),and/or specifying the grade in which teams might be drawn from (e.g. A,B, C etc), and/or specifying or preferencing a particular team, or teams(e.g. ‘The Bears’, ‘The Tigers’ etc), and/or sub-fields to set whetheror not to continue the allocation process if the preferenced teamallocations fail, and/or sub-fields to request a reconfirm once awilling team is found (i.e. electing to receive a further confirmationbefore an allocation is executed), and/or sub-fields to set the methodby which reconfirmation is received (e.g. SMS, email, or some practicalequivalent).

In situations where an allocation request fails because of a lack ofsuitable teams, or lack of teams willing to take a new player, theinitiator might be added to a register or buffer, viewable through theadministrative interface, a ‘player pending list’ or the like. Thebuffer could optionally be used to create teams entirely from playerswithin the buffer. This option would be particularly useful in smallerleagues where spare team capacity is limited, such that any failedallocations might initiate a message to the effect of, “Bot: yourdetails have been added to a buffer, you will be contacted when a teambecomes available”.

The recruit interface might take a range of forms, provided saidinterface acts as a mechanism using which players can initiate anallocation, either to a specific team, e.g. “The Bears”, to a‘recruiting team’, or of a more general nature. The interface mightapply to a singular league or multiple leagues (e.g. acting as arecruitment point for a singular league or multiple leagues, or actingas an allocation mechanism for a singular sport or multiple sports). Theinterface might take a centralized character, e.g. inserted on a pagewithin a league website, or on a page within the website of the bodyoverseeing multiple leagues, or on a page within the website of a thirdparty, or take a decentralized character, such that allocation fieldsand sub-fields might be embedded within discrete and generic web pagesapplying to separate teams. The interface might be implemented using aweb based framework, or within a downloadable or cachedapplication/program framework, or a practically equivalent system usinga direct interface, e.g. making an allocation request by sending an SMSdirectly to the system, or an equivalent system using any other directcommunication, e.g. email, instant messages, MMS or the like, to beginan allocation process. The above systems might act singularly or incombination to allow players and individuals access to a range ofmethods by which to initiate an allocation.

Once administrator preferences are established, particularly the botautonomy level, and team preferences are established, particularly theteam recruiting status, and an allocation is initiated, the data can beacted on by the bot. Besides creating statistical summaries ofcompetitions and grades for administrators, the bot functions to performallocations, particularly by sending spammed or rolling emails, and/orspammed or rolling SMS's, to the most ‘suitable’ teams identified by theranking algorithm.

A ‘rolling’ message is a sequentially distributed message that is sentto a party, responded to or not, and the nature of the responsedetermines the next action. For example, an answer to the negative, or amessage expiry, might cue the system to ‘roll’ the message to the nextparty, where the process is repeated, until a match is found, i.e. anaffirmative response is received. The time a party has to respond mightbe 2 minutes, 50 minutes etc (depending on the message nature andmessage type), and the ‘roll’ might be indefinite, limited to 10parties, or the like. The roll sequence, i.e. the order of messagereception, including who gets preference, is determined by rankingvariables, e.g. sequenced according to the allocation algorithm. Arolling message might take on a range of suitable characters,particularly an SMS or email, such that messages might be replied tothrough the use of keywords or hyperlinks, e.g. “Bot: if interested inreceiving X recruit, reply ‘Y’, or click on the hyperlink”.

The allocation algorithm might use a range of variables for creating theallocation rank list, including initiate details (i.e. the gender, ageof the initiate etc), initiate preferences (i.e. the preferred season,grade, team etc), team details (e.g. team skill, population etc), teampreferences (e.g. preferencing teams set as ‘recruiting’), allocationrequest history (e.g. preferencing teams receiving fewer previousallocation requests), in some weighted combination determined in theallocation algorithm. If the allocation algorithm was being used as acentral point for accessing multiple leagues, it might also considerpost code or the like to match the initiator of the allocation with alocal team.

Thus, a party might initiate an allocation, the bot could construct aroll list sequenced according to the allocation algorithm, a messagemight be sent to the party at the top of the roll list, as an SMS or anemail, responded to or not, if applicable sent to the next party on thelist, and so on, until an affirmative response to the rolling message isreceived. Once received an affirmative response might could cue thesystem to reconfirm an allocation with the initiator, before finalizingthe allocation.

Other contact methods, include using a ‘spam’ approach (i.e. sendingmessages simultaneously, through email, SMS or the like, e.g. to the top5 teams on the rank list), wherein the first party to respond to arequest is allocated the initiator. Using a targeted approach (i.e.sending an automated message to a particular recruiting team only,chosen by the system or the recruit/initiator), or using fields within ateam interface, or within a centralized interface, to display anallocation request equivalent, and offer proximate fields for respondingto said allocation request.

As well as responding to specific join requests, or specificadministrator requests, the league bot might also act autonomously, bycreating lists of contact parties, e.g. potential recruits, particularlylists of dropout players (i.e. players that played the previous but notthe current season), and underemployed players (i.e. fill or temporaryplayers not playing on a weekly basis), created by processing (e.g.performing search functions) the competition database according to therelated preferences in the administration section previously described,and using the results of said search, i.e. the listed dropout andunderemployed parties, to serve as the basis of a contact list, to sendprompts to said parties through rolling messages, spammed messages orthe like with a message either prompting re-registration, or moreregular involvement in a team. For example, the prompt to dropoutplayers might take the form of an SMS or email with the message “Bot:you have not reregistered for the 2008 winter season in league X, reply‘yes’, or click on the hyperlink, if you would like to, and you wouldlike a team found”.

Such a system could work variously to automatically prompt dropout teamswith offers to play next season as a group (i.e. prompt the teamrepresentative to reregister the team), or offer singular players fromdropout teams, detected as having not reregistered within thecompetition, the automated opportunity of playing for a new team or thelike, using the above described method.

Dropout teams are often characterized by several players still wantingto play. The categorical nature of sporting teams, particularly insports with small team populations, means a single team member dropoutcan cause a team implosion, where only a little administrative effortcan assist the team as a whole, or individual players, to re-registerfor the following season. Manually taking such action is difficult,particularly in sports like basketball where a league can have up to1000 teams. Identifying which teams, or indeed players, to target forprompting presents a significant challenge in and of itself,irrespective of the effort required to contact and confirm said teams orplayers. The automated system for identifying and confirming saidparties, and linking the process to a team allocation process, is apractical means of performing the task without burdening administrators.

The prompt to dropout teams or player might take any of the formspreviously described for contact parties in the allocation process, andmight directly replace the process of manually initiating an allocation(e.g. initiating an allocation through a recruit interface on the leaguewebsite), such that a positive reply to a prompt might begin a specificor general team allocation process, such that the sub-fields associatedwith an allocation could be filled in automatically by the system usingthe data associated with said dropout player, e.g. the season and gradesaid player used to play in, could guide any allocation process flowingfrom a prompt.

The bot might also target underemployed players, i.e. players that playoccasionally, or fill in occasionally, that might otherwise like to playmore often, if sufficiently prompted. The bot might use similar systemsto target underemployed players, as described for prompting dropoutplayers, i.e. by analysing the participation level of a particularplayer, in order to construct contact lists etc. The prompt form mighttake any form of those previously described.

Using this combined identification and prompting approach a valuablepercentage of dropout players might be reregistered, and players onlyplaying occasionally might be prompted to play more routinely throughbeing offered positions in teams needing players. Thus not only wouldsuch a system generate direct income (from the extra games played byspecific parties choosing to re-register, or register for more games)but the matches could correct imbalances (e.g. add to the populations ofunder-populated or under-skilled teams) which might otherwise snowballinto forfeits and/or dropouts.

The league bot might take any suitable form provided it singularly orcompositely; offers functions to manage team allocations, dropout playerprompting and underemployed player prompting, including making necessaryconfirmations using a suitable communication system, including email andSMS. The bot may use any coding framework provided it performs the abovedescribed actions.

The allocation and prompting processes may be augmented with a varietyof separate features without departing from the ambit of the invention,including an associated credit merchant, of the ordinary variety, or thelike to charge team join fees, allocation fees, registration fees, orthe like, at any point in the allocation process, including to initiatethe process. Or using premium SMS's, rather than standard SMS's, at somepoint in the allocation process, to bill individuals for the service,through their mobile phone.

These examples serve to illustrate the scope and purpose of the bot andthe system generally, and the specific method by which players andindividuals might automatically have teams found for them, including insuch a way that grade character is complemented, how players fromdisbanded teams might be targeted/prompted for re-registration, howunderemployed players might be targeted/prompted for involvement on aweekly basis, and how the systems tie together, such that prompts feedthe allocation process.

The present invention will now be described in terms of a preferredsystem. It is to be understood that the particularity of theaccompanying description does not supersede the generality of thepreceding description.

In a preferred system the bot would be setup for a particular sportingassociation, at a particular sporting venue, e.g. a particular indoornetball or basketball association, and thus provide a point at which newplayers could join the competition.

In a preferred system the association would be equipped with an ordinarysport administration package, such that said package might centraliseand store competition data, including team and player scores, team winsand losses, player turn-outs for games, and any emergency playersparticipating in said games. Consistently, said bot might process andoperate on said data by being compatible with the major types of sportadministration software.

In a preferred system the bot would be controllable from anadministrative interface, a centralized, private access, web-based page,attached to the association website. The administrative interface wouldinclude bot related preferences and settings which allow for saidadministrator to enable or disable the allocation service generally,select the method by which allocations might be executed (e.g. SMS,email etc), whether ‘recruiting’ teams or any teams might receiveallocation requests, and any upper limits on the number of such requestsreceived (i.e. the maximum number of allocation requests received byrecruiting and other teams).

In a preferred system the administrative interface would includesub-fields for controlling the prompting of dropout players, includingsetting limits on prompts, defining dropout player groups, setting themethod by which prompts are sent (e.g. SMS, email), and setting thegroups uniquely targeted (e.g. seniors players only, players in A gradeonly etc). In a preferred system all of said sub-fields would also beavailable to control prompts sent to underemployed players.

In a preferred system preferences within the administrative interfacewould interact with preferences in discrete team interfaces, private,web-pages, attached to the league web site, that might be used to setteam recruiting status, and view logs of allocation requests.

In a preferred system recruits or individuals seeking teams might makeallocation requests non-exclusively through a public/recruit interface,which might be centralized and web-based, and might take the specificform of a ‘recruit’ page linked to the league website. The page mightinclude fields for personal details, particularly name, age, gender, andthe like, fields describing the group into which the individual wouldlike to be allocated, particularly the season and grade of the desiredallocation, and fields to initiate or submit preferences to begin anallocation process.

In a preferred system an allocation request would be submitted to thebot for processing, within which the bot would create a ranked list ofteams which might suit and/or accept the allocation, such that the listmight be ranked by a weighted algorithm including a combination ofcategorical suitedness (e.g. include teams from appropriate seasons andgrades only, based on initiators gender, age and new/existing playerstatus), team population (such that teams with lower population might bepreferentially targeted), skill (such that lower performing teams mightbe preferentially targeted), recruiting status (such that teamsidentifying themselves as ‘recruiting’ might be preferentiallytargeted), previous approaches (such that teams receiving fewerallocation requests might be preferentially targeted, and teamsreceiving above a particular number of requests might be discountedaltogether) such that said factors might be suitably combined andweighted within said algorithm. In a preferred system any missingranking variables would be automatically compensated for, such that incases where, for example, no skill and/or population data is available,the remaining algorithm components produce a usable rank list.

In a preferred system said list would serve as the basis of a contactlist, and the bot would send out SMS's or emails in a sequential/rollingfashion, in order of the teams position on the allocation rank list,with a message to the effect of “Bot: The league bot has identified yourteam as requiring an additional player, a player has expressed interestin joining, reply ‘yes’, or click on the hyperlink, to allow the playerto join your team's next game.” Such that said message might be,responded to or allowed to timed out, either triggering an allocation,or triggering the sending of the allocation request to the next team onthe rank list, as appropriate and until a match is created. Once thelist is exhausted without an allocation, the initiator of the requestmight be notified and added to a ‘player pending list’ within the leaguedatabase, viewable within the administrative interface.

In a preferred system, logs of allocation requests, received byparticular teams, viewable within said teams team interface, might allowthe team to re-initiate and accept an allocation request, after anddespite initially rejecting it.

In a preferred system dropout and underemployed parties would beidentified through the bot scanning the league database. Parties soidentified, given appropriate selection of administrative preferences,would be sent an SMS or email to the effect of “Bot: X sporting leaguedetected you did not reregister for the current season, some teams in Xgrade are in need of players, reply ‘yes’, or click on the hyperlink, ifyou would like a team found, and to play in the current seasons. In apreferred system underemployed players would be similarly identified andsent an SMS to the effect of “Bot: Z sporting league detected you areonly playing in X % of games, some teams in Y grade are in need of morepermanent players, reply ‘yes’, or click on the hyperlink, if you wouldlike a more permanent position in a team found”.

In a preferred system positive replies to said prompts would cue anallocation process, as though the player had made an allocation requestthrough the recruit interface, while a negative or null response fromsaid parties would be added to a log, in order to track and put a limiton future such prompts sent to the same party.

In a preferred system said functions would act organically andsemi-autonomously to selectively augment team populations, andre-incorporate and better incorporate players into competitions.

Embodiments of the present invention will now be described, by way ofexample only, with reference to the accompanying drawings. It is to beunderstood that the particularity of the accompanying drawings does notsupersede the generality of the preceding description of the invention:

In the drawings

FIG. 1 is a schematic block diagram of the recruit manager system andvarious possible features of the system;

FIG. 2 is a flow chart of the steps involved in initiating anallocation;

FIG. 3 is a flow chart of the steps involved in setting up the system,at an administrative level.

FIG. 4 is a flow chart of the steps involved in creating an allocationrank list;

FIG. 5 is a flow chart of the steps associated with setting team status,particularly team recruiting status;

FIG. 6 is a flow chart of the steps associated with the allocationprocess;

FIG. 7 is a flow chart of the steps associated with prompting dropoutand underemployed players;

FIG. 8 is a flow chart of the steps associated with re-initiating andaccepting an allocation request, after it has been preliminarilyrejected;

FIG. 9 is a screen dump of the administrative interface;

FIG. 10 is a screen dump of the team interface for setting teamrecruiting status, and viewing and re-initiating rejected allocationrequests;

FIG. 11 is a screen dump of recruit interface for initiatingallocations;

FIG. 12 is a screen dump of the processing page displayed when anallocation is submitted and initiated;

FIG. 13 is a screen dump of the confirmation page displayed after theallocation process is complete, and has been successful;

Referring to FIG. 1. the recruiting and allocation system 10 uses acommunication system 120, such as the internet and/or telecommunicationsservice, to facilitate the allocation of initiators 19 to sporting teams1202, particular in ways which complement grade 1201 character (i.e. to‘balance’ grades), and functions to identify and prompt individuals,particularly dropout players 193 and underemployed players 194, to bere-involved or more involved in the league.

More specifically system 10 can provide;

Functions to automatically allocate initiators 19 to teams 1202, byaccepting allocation requests at S65, constructing ranked lists of themost suitable teams at S66, communicating with said teams at S672 orS671, and once a willing team is found, allocating said player to saidteam at S611 or S614, and sending relevant notifications S6102 or S6132to relevant parties;

Functions to automatically identify ‘dropout’ players from league datastored on database 16, and construct lists of said identified dropoutsat S73, using said lists to send email or SMS allocation prompts at S74to said dropout players. If a positive response is received at S75, theresponse might initiate an allocation as though said individual used arecruit interface;

Functions to automatically identify ‘underemployed’ players from leaguedata stored on database 16, in a manner similar to that described fordropout players.

Allocation requests might be made by new players 191, existing players192 looking for a new team, dropout players 193 looking to be reinvolvedin a competition, or underemployed players 194 looking to play on a moreregular basis. The requests can be made through recruiting interface 12which might take the form of FIG. 11. The recruit interface allows anindividual seeking entry into a sporting competition, or the like, toenter personal preferences at S21, including the individuals name S215,age S211, gender S212, mobile phone number S213 and email S214, andoptionally enter recruit preferences at S22, including the preferredseason S221 (e.g. men's, women's, mixed etc) and grade S222 within whichthe individual would like a team found, and any preferred teams S223.Other options, depicted variously in FIG. 11, include only contactingpreferred teams S2231, and choosing whether or not the process requiresan additional confirmation S2241, at S682 for example, prior to beingallocated a team. All data apart from S21 personal details is optionalto initiate an allocation. Once the personal details and preference havebeen finalized the allocation can be initiated by submitting the pagefor processing at S225, by clicking on the ‘submit’ button depicted inFIG. 11.

Once the allocation request of a particular individual is submitted atS225 the request moves through network 120 to server 16 where it isprocessed at S66 by bot algorithm 141. The processing stage generatesallocation rank-list 142, a ranked list of potential recipient teams,from ‘most suitable’ to ‘least suitable’, for that particular player.The algorithm might process and operate on a range of variables,including;

-   -   administrative filtering S413, i.e. whether the administrator        has specified that only teams actively setting their status as        ‘recruiting’ within team interface 13 are sent allocation        requests;    -   personal detail filtering S432, i.e. filtering teams        inconsistent with the personal details of initiator 19,        including age and gender;    -   team population ranking S44, i.e. assigning ‘weights’ to        particular teams based on their population, such that teams with        lower populations are preferenced for allocations;    -   team skill ranking S45, i.e. assigning ‘weights’ to particular        teams based on their skill or performance, such that teams with        lower performance records, as drawn by the bot from database 16,        are preferenced for allocations;    -   team recruiting status ranking S46, i.e. assigning ‘weights’ to        teams based on whether or not they are set as ‘recruiting’.    -   previous allocation requests S47, i.e. assigning ‘weights’ to        particular teams based on previous allocation requests received,        such that teams receiving fewer allocation requests, or no        allocation requests, might be preferenced for allocations.    -   combining said variables to produce a rank list at S48, such        that missing variables, e.g. the absence of team skill or        population data, can be compensated for, including by employing        randomized ranking where necessary.

Team recruiting status is controllable within team interface 13 depictedin FIG. 10. If a team judges it is in need of, will be in need of, orwould like additional team members, the team status can be set to‘recruiting’ at S52. This involves choosing the number of recruitsneeded in S53, inserting any special message to recruits at S54, settingrecruitment visibility at S55 (i.e. whether a teams recruiting status ismade viewable on public league data structures) and submitting therequest at S56. As specified with the description of the allocation rankprocess, this will have one of two effects, either preferencing the teamwhen constructing an allocation rank list at S46, i.e. increasing thepriority with which the team receives allocation requests, or unlockingthe team to receive allocation requests at S413, such thatadministrators might filter allocation requests to non-recruiting teamsat S312 to only be received by ‘recruiting teams’.

Recruiting team filtering is a discretionary selectable option withinadministrative interface 11 depicted in FIG. 8. It might be used torestrict allocations to recruiting teams only. Other options andpreferences include fields to enable or disable allocations generally atS31. If selected, it might block the bot from making allocationsaltogether by hiding and blocking access to recruit interface 12. Otheroptions include specifying the method by which allocations are madeS311, e.g. whether allocation requests are sent via email or SMS, atS67, or setting upper limits on allocation requests sent tonon-recruiting teams, depicted variously in FIG. 8.

The allocation rank-list 142 acts as a contact list for sendingallocation requests to teams, i.e. asking said teams to receive saidinitiator. Messages might take the form of either emails or SMS's, asdetermined by the administrator at S311, and might be sent sequentiallyin order of position within rank-list 142 at S672, particularly forSMS's, or spammed to several of the top ranked teams at S671,particularly for emails. SMS's are sent through SMSC server 18 throughchannel 181, while emails can be sent directly by the bot from network120.

If SMS messages are used to send allocation requests at S672, teams canrespond through replying to the message, e.g. replying ‘yes’, ‘no’ etc,which is received by the bot through channel 182. The reply might beaffirmative (accepting the join request), negative (declining the joinrequest), or ignored (nor responding to the allocation request). Theresponse of the team will determine what action the bot will take, suchthat a positive response will cue the bot to request final confirmationfrom the initiator at S682, if specified in the recruit interface, orsend notification to the initiator at S6102 that the allocation has beenfound and made, when-after the database is updated to reflect theallocation at S611. A negative response, on the other hand, or noresponse at S68 within a reasonable time-out limit, will add the team tothe approached log 164 at S681, and will cue the bot to ask the nextteam on allocation rank-list 142 at S69. If or when rank-list 142 isexhausted, and an allocation has not been made, the bot will inform theinitiator that no match is possible, through an appropriate message, atS615. Initiators informed as such might be added to a centralizedregister of players awaiting teams, a ‘player pending list’ 162 at S616.

If emails are used to send allocation requests at S671, teams canrespond by clicking on an appropriate hyperlink, which is received bythe bot through network 120. The steps and processes flowing from emailbased replies to allocation requests is the same as that for SMS basedreplies, barring if multiple allocations are sent simultaneously, afirst come first serve principle applies, such that the first team torespond positively to the email based allocation request receives saidplayer, while the remaining teams that received allocation requests areissued relevant notifications. Again, if no such affirmation of anallocation request is forthcoming, an appropriate message is sent atS615 to inform the initiator that no allocation is possible at thistime, while the initiator is added to player pending list 162 at S616.

It is possible for a team to accept an allocation, although and after ithas F been initially rejected or allowed to timeout. All allocationrequests are stored and viewable as logs within team interface 13depicted under logs in FIG. 10, such that teams might view when and ifan allocation request was received, and the teams response. At S83software within the team interface determines whether an initiatorlisted in the log was ultimately allocated a team, i.e. did theinitiator end up in player pending list 162. If not, a re-initiate fieldis provided next to said log, enabling the team to re-continue andaccept the allocation at S832. If the initiator is not in the playerpending list, the re-initiate field is hidden S831. Allocationsre-initiated using this method are parsed to S682, for using SMS basedallocation requests, or S6121, for using email based allocationrequests.

As well as passively receiving and processing allocation requests fromthe initiator, through a recruit interface or the like, the bot can alsoact autonomously to prompt individuals to act as initiators. Individualsthat receive prompts fall into two categories, dropouts or underemployedplayers.

Prompts sent to dropout players are setup and controllable withinadministrative interface 11, such that particular fields might enablethe prompting of dropout players to be enabled or disabled generally atS32, that the method by which dropout prompts are sent be specified atS321, including whether interactive SMS's or emails are used as prompts,that upper limits on dropout prompts be set at S323 (e.g. the maximumnumber of prompts sent to a particular dropout), that dropouts bedefined at S322 (i.e. the time range since leaving a league a player isregarded as a ‘dropout’, e.g. 0-12 months etc) that particular groupswithin the dropout population be targeted at S334 (e.g. groups fromseniors only, groups from A grade only, all groups except juniors etc),as depicted variously in FIG. 9.

The same fields and sub-fields might be available to systems targetingunderemployed players, such that particular fields might enable ordisable the prompting of underemployed players at S33, set limits on thenumber of prompts said to such parties at S333, set the method by whichunderemployed players are prompted at S331, define the participationrange within which a player might be defined as underemployed at S332(e.g. target players participating in between 10% and 40% of games), andset the groups within which underemployed players might be targeted atS334 (e.g. target underemployed players in A grade only etc).

Once discrete settings for dropout and underemployed players areestablished, the bot might prompt said parties, according toadministration settings, using an SMS sent through outgoing channel 181through SMSC 18, at S74. The SMS prompt sent at S741 to partiesidentified as dropout players might take the form of “League Bot: thesystem has detected you did not reregister for the current season, reply‘yes’ if you would like to reregister in league X this season, by doingso you will automatically be allocated a team”.

Under this system a positive reply to said message at S75, indicatingthe dropout player would like to play in the current season, would bereceived through gateway 182, and trigger the allocation processbeginning at S65 and continue as previously described. A ‘negative’answer, or no answer for specified duration, at S75, will mark theplayer as ‘approached’ in approached log 164 in database 16 at S751.

The dropout player might also be prompted with an email at S742, suchthat instead of replying a keyword, said dropout might click a hyperlinkor the like at S582.

Similar systems might apply to underemployed players such that saidparties are sent prompts at S74, which might be SMS S741 or email S742based, which might be replied to in an appropriate method, such that apositive reply to said message at S75, indicating the underemployedplayer would like to play on a weekly basis, would start-up theallocation process beginning at S65 and continuing as previouslydescribed. A ‘negative’ answer at S751, or no response within adesignated timeout period, will mark the underemployed player as‘approached’ in log 164.

It is to be understood that various alterations, additions and/ormodifications may be made to the parts previously described withoutdeparting from the ambit of the present invention, and that, in thelight of the above teachings, the present invention may be implementedin software, firmware and/or hardware in a variety of manners as wouldbe understood by the skilled person.

Further it is also to be understood that the present invention might beimplemented with all, several or one of the features described,specifically including, but not limited to, being implemented as asingular system for performing allocations, a singular system promptingdropout players and/or a singular system for prompting underemployedplayers, in any of the variations previously described.

The present application may be used as a basis for priority in respectof one or more future applications, and the claims of any such futureapplication may be directed to any one feature or combination offeatures that are described in the present application. Any such futureapplication may include one or more of the following claims, which aregiven by way of example and are non-limiting with regard to what may beclaimed in any future application.

1. A recruit and allocation management system for a sports leagueimplemented over an electronic communications network, including: aleague ‘bot’, a semi-autonomous program that manages the playerallocation process, including performing strategic individual/teamallocations, and identifying parties that might serve as recruits/‘new’players; an administrative interface, for league administrators to setbot preferences; a team interface, for teams to interact with the bot,including setting team recruiting status, and viewing logs of allocationrequests; a recruit interface, for recruits/individuals to interact withthe bot, including cueing making a particular or general allocationrequest; and a database containing league data, bot lists, administratorpreferences, team preferences, recruit details etc.
 2. The system ofclaim 1, wherein allocation initiators and prospective teams arecontacted by electronic messaging.
 3. The system of claim 1, whereinallocation initiators and prospective teams are contacted by email. 4.The system of claim 1, wherein allocation initiators and prospectiveteams are contacted through a telecommunications messaging service,selected from one of SMS, EMS or MMS messaging.
 5. The system of claim1, wherein allocation initiators and prospective teams are contactedthrough a web interface, e.g. through posting a message to a privateweb-page.
 6. The system of claim 1, wherein a plurality of prospectiveteams are contacted at the same time.
 7. The system of claim 6, whereinthe team to respond positively first is assigned the allocation.
 8. Thesystem of claim 6, wherein once a team accepts an initiators allocationrequest, other alerted teams are notified that there is no longer aplayer seeking a team.
 9. The system of claim 1, wherein prospectiveteams are contacted sequentially.
 10. The system of claim 1, wherein anallocation request made to a prospective team includes response data orlinks for responding to said alert.
 11. The system of claim 1, whereinonce an allocation is made, the initiator and accepting team arenotified of the match.
 12. The system of claim 1, wherein said recruitinterface allows an initiator to specify preferences including preferredseason, grade, or teams to join.
 13. The system of claim 1, wherein saidteam interface allows teams to flag themselves as ‘recruiting’.
 14. Thesystem of claim 1, wherein said allocation request is submitted to aprospective team via a telecommunications network.
 15. The system ofclaim 1, wherein said allocation request is submitted to a prospectiveteam via an SMS message.
 16. The system of claim 1, wherein saidallocation request is submitted to a prospective team via an email. 17.The system of claim 1, wherein said allocation request is submitted to aprospective team via a log in an interface, e.g. a log in a private teaminterface.
 18. The system of claim 1, wherein said system can identify‘dropout’ players.
 19. The system of claim 1, wherein said system canidentify ‘underemployed’ players.
 20. The system of claim 1, whereinsaid system can identify ‘dropout’ players and ‘underemployed’ players,and wherein dropout and underemployed players are contacted byelectronic messaging.
 21. The system of claim 20 wherein dropout andunderemployed players are contacted by email.
 22. The system of claim21, wherein dropout and underemployed players are contacted through atelecommunications messaging service selected from one of SMS, EMS orMMS messaging.
 23. The system of claim 20, wherein said positiveresponses to said contacts, by dropouts or underemployed players, areused procedurally in place of an initiation made through the recruitinterface.
 24. The system of claim 1, wherein play history data,personal and preferential, associated with a dropout or underemployedplayer is used in place of manually entered data in the recruitinterface.
 25. The system of claim 1, wherein said recruit interfaceallows a player to view lists of recruiting teams.
 26. The system ofclaim 1, wherein said recruit interface allows said system to save orstore interest in joining a team, e.g. to a player pending list.
 27. Thesystem of claim 1, wherein said system includes a website in whichallocation requests and player requests might be submitted by playersand teams respectively.
 28. A method for automating the allocation of anindividual to a sporting team using an electronic communicationsnetwork, including the steps of; providing a recruit interface for anindividual to register for the allocation service; providing a teaminterface for a team to register as ‘recruiting’; creating a list of‘suitable’ teams for the initiator, sending allocation requests to saidteams, and awaiting a positive reply, which if forthcoming might promptnotifications to relevant parties and the initiator to be added to therelevant team list.
 29. The system of claim 28, wherein player to teammatching is performed through analysing age/gender, and/or team skill,and/or team population, and/or team recruiting status, and/or previoussimilar contacts made to teams.
 30. A method for prompting parties,particularly dropout and underemployed parties, to use an allocationengine, or express an interest in rejoining or changing teams in aleague, including the steps of; providing an administrative interface tosetup prompting systems; sending prompts in the form of messages to saidparties, with reply mechanisms; and receiving responses and eitherstoring said responses, or using said responses to initiate anallocation or equivalent process.
 31. A recruit and allocationmanagement system for a sports league implemented over an electroniccommunications network, including: a league ‘bot’, a semi-autonomousprogram that manages the player allocation process, including performingstrategic individual/team allocations, and identifying parties thatmight serve as recruits/‘new’ players; any one or more of the followinginterfaces: (a) an administrative interface, for league administratorsto set bot preferences; (b) a team interface, for teams to interact withthe bot, including setting team recruiting status, and viewing logs ofallocation requests; (c) a recruit interface, for recruits/individualsto interact with the bot, including cueing making a particular orgeneral allocation request; and a database containing league data, batlists, administrator preferences, team preferences, recruit details etc.